 first | Daisy Diff compare report.
Click on the changed parts for a detailed description. Use the left and right arrow keys to walk through the modifications. |
last  |
| first | Daisy Diff compare report.
Click on the changed parts for a detailed description. Use the left and right arrow keys to walk through the modifications. |
last |
| Version | Date | Comment | |
|---|---|---|---|
| v 1.0 | 20142013-10-2021 | Initial releaseRelease | |
| v 1.1 | 2014-1101-05 | Addition to TLS cipher suite selections | |
| v 1.2 | 2016-04-22 | Added server-side TLS requirements (selection-based)
Multiple clarification based on NIAP TRRT inquiries Refactored FDP_DEC_EXT.1 into separate components |
|
| v 1.3 | 2019-03-01 | Incorporated available Technical Decisions
Refactored FPT_TUD Added a selection to FTP_DIT Moved SWID Tags requirement Leveraged TLS Package Added equivalency section |
|
| v 1.4 | 2021-10-07 | Incorporated applicable Technical Decisions
Updated to TLS FP 1.1 Incorporated SSH FP 1.0 12 | Typographical changes and additional clarifications in application notes. Removed
assignment from FCS_TLS_EXT.1 and limited testing to those ciphersuites in both FCS_TLS_EXT.1 and FCS_TLS_EXT.2. |
| 2.0 | 2015-09-14 | Included changes based on Technical Rapid Response Team Decisions. Clarified many
requirements and evaluation activities. Mandated objective requirements:Application Access Control (FDP_ACF_EXT.1.2)VPN Information Flow Control (FDP_IFC_EXT.1) Added new objective requirements:Suite B cryptography for IEEE 802.11Certificate enrollmentProtection of additional key material typesHeap overflow protectionBluetooth requirementsCryptographic operation services for applicationsRemote Attestation (FPT_NOT_EXT.1) Added transition dates for some objective requirements. Included hardware-isolated REK and key storage selections. Allowed key derivation by REK. Clarified FTP_ITC_EXT.1 and added FDP_UPC_EXT.1. Mandated HTTPS and TLS for application use. (FDP_UPC_EXT.1) Removed Dual_EC_DRBG as an approved DRBG. Adopted new TLS requirements. Mandated TSF Wipe upon authentication failure limit and required number of authentication failures be maintained across reboot. Clarified Management Class. Included more domain isolation discussion and tests. Updated Audit requirements and added Auditable Events table. Added SFR Category Mapping Table. Updated Use Case Templates. Moved Glossary to Introduction. |
|
| 3.0 | 2015-09-17 | Included changes based on Technical Rapid Response Team Decisions. Clarified
many requirements and evaluation activities. Mandated objective requirements:Generation of Audit Records (FAU_GEN.1)Audit Storage Protection (FAU_STG.1)Audit Storage Overwrite (FAU_STG.4)Lock Screen DAR (FDP_DAR_EXT.2)Discard Bluetooth Connection Attempts from Bluetooth Addresses with Existing Connection (FIA_BLT_EXT.3)JTAG Disablement (FPT_JTA) Added new objective requirements:Application BackupBiometric Authentication FactorAccess ControlUser AuthenticationBluetooth Encryption WLAN client requirements moved to Extended Package for WLAN Client. Added SFRs to support BYOD Use Case BYOD Use Case Updated key destruction SFR |
|
| 3.1 | 2017-04-05 | Included changes based on Technical Rapid Response Team Decisions and incorporated
Technical Decisions. Modified biometric requirements: FIA_UAU.5 - Added iris, face, voice and vein as supported modalities, in addition to fingerprint (allowed in version 3)FIA_BMG_EXT.1.1 - Clarified AA to specify that vendor evidence is acceptable and expectations of evidence provided. FIA_BMG_EXT.1.2 - SAFAR was changed to an assignment of a SAFAR no greater than 1:500. FIA_AFL_EXT.1 - Updated to allow each biometric modality to utilize an individual or shared counter. FCS_TLSC_EXT.1.1 - Removed TLS ciphersuites that utilized SHA1 and updated optional ciphersuites to be uniformed across PPs. FCS_STG_EXT.2.2 - Modified to require long term trusted channel key material be encrypted by an approved method. FIA_UAU_EXT.1.1 - Modified to allow the long term trusted channel key material to be available prior to password being entered at start-up. |
|
| 3.2 | 2021-04-15 | Removed TLS SFRs and utilized TLS Functional Package Removed Bluetooth SFRs
and utilized Bluetooth Module. Bluetooth SFR moved to Implementation Dependent. FPT_TUD_EXT.4.2 renumbered to |
|
| 3.3 | 2022-09-12 | Integrated Biometrics cPP Module, Included changes based on Technical Rapid Response Team Decisions and open issues from GitHub.Removed biometric definitions from Tech TermsRemoved FDP_PBARemoved FIA_BMGUpdated FIA_UAU.5 to support bio cPP moduleMoved FTA_TAB.1 to mandatoryMoved FAU_SAR.1 to mandatoryAdded ECDUpdated WLAN Client reference from Extended Package to ModuleRemoved Diffie-Hellman group 14 selection from FCS_CKM.1.1 and FCS_CKM.2.1/UNLOCKED |
|
Assurance
| Grounds for confidence that a TOE meets the SFRs [CC]. |
|
Base Protection Profile (Base-PP)
| Protection Profile used as a basis to build a PP-Configuration. |
|
Collaborative Protection Profile (cPP)
| A Protection Profile developed by international technical communities and approved by multiple schemes. |
|
Common Criteria (CC)
| Common Criteria for Information Technology Security Evaluation (International Standard ISO/IEC 15408). |
|
Common Criteria Testing Laboratory
| Within the context of the Common Criteria Evaluation and Validation Scheme (CCEVS), an IT security evaluation facility |
| accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and approved by the NIAP Validation Body to conduct Common Criteria-based evaluations. | |
|
Common Evaluation Methodology (CEM)
| Common Evaluation Methodology for Information Technology Security Evaluation. |
|
Distributed TOE
| A TOE composed of multiple components operating as a logical whole. |
|
Extended Package (EP)
| A deprecated document form for collecting SFRs that implement a particular protocol, technology, or functionality. See Functional Packages. |
|
Functional Package (FP)
| A document that collects SFRs for a particular protocol, technology, or functionality. |
|
Operational Environment (OE)
| Hardware and software that are outside the TOE boundary that support the TOE functionality and security policy. |
|
Protection Profile (PP)
| An implementation-independent set of security requirements for a category of products. |
|
Protection Profile Configuration (PP-Configuration)
| A comprehensive set of security requirements for a product type that consists of at least one Base-PP and at least one PP-Module. |
|
Protection Profile Module (PP-Module)
| An implementation-independent statement of security needs for a TOE type complementary to one or more Base |
| -PPs. | |
|
Security Assurance Requirement (SAR)
| A requirement to assure the security of the TOE. |
|
Security Functional Requirement (SFR)
| A requirement for security enforcement by the TOE. |
|
Security Target (ST)
| A set of implementation-dependent security requirements for a specific product. |
|
Target of Evaluation (TOE)
| The product under evaluation. |
|
TOE Security Functionality (TSF)
| The security functionality of the product under evaluation. |
|
TOE Summary Specification (TSS)
| A description of how a TOE satisfies the SFRs in an ST. |
|
Address Space Layout Randomization
|
|
| An anti-exploitation feature, which loads memory mappings into unpredictable locations. ASLR makes it more difficult for an attacker to redirect control to code that they have introduced into the address space of |
| a process or the kernel. |
|
Administrator
| The Administrator is responsible for management activities, including setting the policy that is applied by the enterprise on the Mobile Device. This administrator is likely to be acting remotely and could be the Mobile Device Management (MDM) Administrator acting through an MDM Agent. If the device is unenrolled, the user is the administrator. |
|
Auxiliary Boot Modes
| Auxiliary boot modes are states in which the device provides power to one or more components to provide an interface that enables an unauthenticated user to interact with either a specific component or several components that exist outside of the device’s fully authenticated, operational state. |
|
Biometric Authentication Factor
| Authentication factor, which uses biometric sample, matched to a biometric authentication template to help establish identity. |
|
Common Application Developer
| Application developers (or software companies) often produce many applications under the same name. Mobile devices often allow shared resources by such applications where otherwise resources would not be shared. |
|
Critical Security Parameter
| Security-related information whose disclosure or modification can compromise the security of a cryptographic module or authentication system. |
|
Data
| Program/application or data files that are stored or transmitted by a server or Mobile Device (MD). |
|
Data Encryption Key
| A key used to encrypt data-at-rest. |
|
Developer Modes
| Developer modes are states in which additional services are available to a user in order to provide enhanced system access for debugging of software. |
|
Encrypted Software Keys
| These keys are stored in the main file system encrypted by another key and can be changed and sanitized. |
|
Enrolled State
| The state in which the Mobile Device is managed with active policy settings from the administrator. |
|
Enterprise Data
| Enterprise data is any data residing in the enterprise servers, or temporarily stored on Mobile Devices to which the Mobile Device user is allowed access according to security policy defined by the enterprise and implemented by the administrator. |
|
Ephemeral Keys
| These keys are stored in volatile memory. |
|
File Encryption Key
| A DEK used to encrypt a file or a director when File Encryption is used. FEKs are unique to each encrypted file or directory. |
|
Hardware-Isolated Keys
| The OS can only access these keys by reference, if at all, during runtime. |
|
Hybrid Authentication
| A hybrid authentication factor is one where a user has to submit a combination of a biometric sample and a PIN or password and both must pass. If either factor fails, the entire attempt fails. The user shall not be made aware of which factor failed, if either fails. |
|
Immutable Hardware Key
| These keys are stored as hardware-protected raw key and cannot be changed or sanitized. |
|
Key Chaining
| The method of using multiple layers of encryption keys to protect data. A top layer key encrypts a lower layer key, which encrypts the data; this method can have any number of layers. |
|
Key Encryption Key
| A key used to encrypt other keys, such as DEKs or storage that contains keys. |
|
Locked State
| Powered on but most functionality is unavailable for use. User authentication is required to access functionality. |
|
MDM Agent
| The MDM Agent is installed on a Mobile Device as an application or is part of the Mobile Device’s OS. The MDM Agent establishes a secure connection back to the MDM Server controlled by the administrator. |
|
Minutia Point
| Friction ridge characteristics that are used to individualize a fingerprint image. Minutia are the points where friction ridges begin, terminate, or split into two or more ridges. In many fingerprint systems, the minutia points are compared for recognition purposes. |
|
Mobile Device
| A device which is composed of a hardware platform and its system software. The device typically provides wireless connectivity and may include software for functions like secure messaging, email, web, VPN (Virtual Private Network) connection, and VoIP (Voice over IP), for access to the protected enterprise network, enterprise data and applications, and for communicating to other Mobile Devices. |
|
Mobile Device Management
| Mobile device management (MDM) products allow enterprises to apply security policies to mobile devices. This system consists of two primary components: the MDM Server and the MDM Agent. |
|
Mobile Device User
| The individual authorized to physically control and operate the Mobile Device. Depending on the use case, this can be the device owner or an individual authorized by the device owner. |
|
Modality
| A type or class of biometric system, such as fingerprint recognition, facial recognition, iris recognition, voice recognition, signature/sign, and others. |
|
Mutable Hardware Key
| These keys are stored as hardware-protected raw key and can be changed or sanitized. |
|
Operating System
| Software that runs at the highest privilege level and can directly control hardware resources. Modern Mobile Devices typically have at least two primary operating systems: one, which runs on the application processor and one, which runs on the cellular baseband processor. The OS of the application processor handles most user interactions and provides the execution environment for apps. The OS of the cellular baseband processor handles communications with the cellular network and may control other peripherals. The term OS, without context, may be assumed to refer to the OS of the application processor. |
|
PIN Authentication Factor
| A PIN is a set of numeric or alphabetic characters that may be used in addition to a biometric factor to provide a hybrid authentication factor. At this time it is not considered as a stand-alone authentication mechanism. A PIN is distinct from a password in that the allowed character set and required length of a PIN is typically smaller than that of a password as it is designed to be input quickly. |
|
Password Authentication Factor
| A type of authentication factor requiring the user to provide a secret set of characters to gain access. |
|
Powered Off State
| The device has been shut down such that no TOE function can be performed. |
|
Protected Data
| Protected data is all non-TSF data, including all user or enterprise data. Some or all of this data may be considered sensitive data as well. |
|
Root Encryption Key
| A key tied to the device used to encrypt other keys. |
|
Sensitive data
| Sensitive data shall be identified in the TSS section of the Security Target (ST) by the ST author. Sensitive data is a subset or all of the Protected data. Sensitive data may include all user or enterprise data or may be specific application data such as emails, messaging, documents, calendar items, and contacts. Sensitive data |
| is protected while in the locked state (FDP_DAR_EXT.2). | |
|
Software Keys
| The OS access the raw bytes of these keys during runtime. |
|
TSF Data
| Data for the operation of the TSF upon which the enforcement of the requirements relies. |
|
Trust Anchor Database
| A list of trusted root Certificate Authority certificates. |
|
Unenrolled State
| The state in which the Mobile Device is not managed. |
|
Unlocked State
| Powered on and device functionality is available for use. Implies user authentication has occurred (when so configured). |
|
Verification
| A task where the biometric system attempts to confirm an individual’s claimed identity by comparing a submitted sample to one or more previously enrolled authentication templates. |
Although the requirements in this document apply to a wide range of application software, consult guidance from the relevant national schemes to determine when formal Common Criteria evaluation is expected for a particular type of application. This may vary depending upon the nature of the security functionality of the application.
Applications include a diverse range of software such as office suites, thin clients, PDF readers, downloadable smartphone apps, and apps running in a cloud container. The TOE includes any software in the application installation package, even those pieces that may extend or modify the functionality of the underlying platform, such as kernel drivers. Many platforms come bundled with applications such as web browsers, email clients and media players and these too should be considered subject to the requirements defined in this document although the expectation of formal Common Criteria evaluation depends upon the national scheme. BIOS and other firmware, the operating system kernel, and other systems software (and drivers) provided as part of the platform are outside the scope of this document.
The following PPs and PP-Modules are allowed to be specified in a PP-Configuration with this PP.
Several of the use case templates include objective requirements that are strongly desired for the indicated use cases. Readers can expect those requirements to be made mandatory in a future revision of this protection profile, and industry should aim to include that security functionality in products in the near-term.
As of publication of this version of the Protection Profile, meeting the requirements in is necessary for all use cases.
Mobile devices are subject to the threats of traditional computer systems along with those entailed by their mobile nature. The threats considered in this PP are those of network eavesdropping, network attacks, physical access, malicious or flawed applications, persistent presence, and backup as detailed in the following sections.
| Threat, Assumption, or OSP | Security Objectives | Rationale | ||
| T. | NETWORKMALICIOUS_ | ATTACK​APP | O.PROTECTED_COMMSAUTH | The threat T.MALICIOUS_APP is countered by O.AUTH as this provides the capability to authenticate the user and endpoints of a trusted path to ensure they are communicating with an authorized entity with appropriate privileges. |
| O.CONFIG | The threat T. | |||
| MALICIOUS_ | ||||
| APP is countered by O. | ||||
| CONFIG as this provides | ||||
| the capability to configure and apply security policies to ensure the Mobile Device can protect user and enterprise data that it may store or process. | ||||
| O.INTEGRITY | The threat T.NETWORKMALICIOUS_ATTACKAPP is countered by O.INTEGRITY as this provides for the capability to perform self-tests to ensure the integrity of software that is installed onto the system from the network.O.MANAGEMENTcritical functionality, software/firmware and data has been maintained. | |||
| O.PRIVACY | The threat T.MALICIOUS_APP is countered by O.PRIVACY as this provides separation and privacy between user activities. | |||
| O.PROTECTED_​COMMS | The threat T.MALICIOUS_APP is countered by O.PROTECTED_COMMS as this provides the capability to communicate using one (or more) standard protocols as a means to maintain the confidentiality of data that are transmitted outside of the TOE. | |||
| T.NETWORK_​ATTACK | O.AUTH | The threat T.NETWORK_ATTACK is countered by O. | ||
| AUTH as this provides | ||||
| authentication of the endpoints of a trusted communication path. | ||||
| O.CONFIG | The threat T.NETWORK_ATTACK is countered by O.CONFIG as this provides a secure configuration of the mobile device to protect data that it processes. | |||
| O.PROTECTED_ | ||||
| ​COMMS | The threat T.NETWORK_ | |||
| ATTACK is countered by O.PROTECTED_COMMS as this provides | ||||
| O.QUALITY | The objective O.QUALITY ensures use of mechanisms that provide protection against network-based attack. | |||
| O.MANAGEMENTthe capability to communicate using one (or more) standard protocols as a means to maintain the confidentiality of data that are transmitted outside of the TOE. | ||||
| T.NETWORK_​EAVESDROP | O.AUTH | The threat T.NETWORK_EAVESDROP is countered by O.AUTH as this provides authentication of the endpoints of a trusted communication path. | ||
| O.CONFIG | The threat T.NETWORK_EAVESDROP is countered by O.MANAGEMENTCONFIG as this provides for the ability to configure the application to protect the confidentiality of its transmitted dataa secure configuration of the mobile device to protect data that it processes. | |||
| O.PROTECTED_​COMMS | The threat T.NETWORK_EAVESDROP is countered by O.PROTECTED_COMMS as this provides the capability to communicate using one (or more) standard protocols as a means to maintain the confidentiality of data that are transmitted outside of the TOE. | |||
| T. | LOCALPERSISTENT_ | ATTACK​PRESENCE | O.QUALITYINTEGRITY | The objective O.QUALITY protects against the use of mechanisms that weaken the TOE with regard to attack by other software on the platform. |
| T.PHYSICAL_ACCESS
| O.PROTECTED_STORAGE | The objective O.PROTECTED_STORAGE protects against unauthorized attempts to access physical storage used by the TOE. | ||
| A.PLATFORM
| OE.PLATFORMthreat T.PERSISTENT_PRESENCE is countered by O.INTEGRITY as this provides the capability to perform self-tests to ensure the integrity of critical functionality, software/firmware and data has been maintained. | |||
| O.PRIVACY | The threat T.PERSISTENT_PRESENCE is countered by O.PRIVACY as this provides separation and privacy between user activities. | |||
| T.PHYSICAL_​ACCESS | O.AUTH | The threat T.PHYSICAL_ACCESS is countered by O.AUTH as this provides the capability to authenticate the user prior to accessing protected functionality and data. | ||
| O.STORAGE | The threat T.PHYSICAL_ACCESS is countered by O.STORAGE as this provides the capability to encrypt all user and enterprise data and authentication keys to ensure the confidentiality of data that it stores. | |||
| A.CONFIG | OE.CONFIG | The operational environment objective OE.PLATFORMCONFIG is realized through A.PLATFORMCONFIG. | ||
| A.PROPER_USERNOTIFY | OE.PROPER_USERNOTIFY | The operational environment objective OE.PROPER_USERNOTIFY is realized through A.PROPER_USERNOTIFY. | ||
| A.PRECAUTION | OE.PRECAUTION | The operational environment objective OE.PRECAUTION is realized through A.PRECAUTION. | ||
| A.PROPER_ADMIN​USER | OE.PROPERDATA_ADMIN​PROPER_​USER | The operational environment objective OE.DATA_PROPER_ADMINUSER is realized through A.PROPER_ADMINUSER. |
Any file that may potentially contain sensitive data (to include temporary files) shall be protected. The only exception is if the user intentionally exports the sensitive data to non-protected files. ST authors should select "protect sensitive data in accordance with FCS_STO_EXT.1" for the sensitive data that is covered by the FCS_STO_EXT.1 SFR.
If not store any sensitive data is selected, the evaluator shall inspect the TSS to ensure that it describes how sensitive data cannot be written to non-volatile memory. The evaluator shall also ensure that this is consistent with the filesystem test below.
The evaluator shall inventory the filesystem locations where the application may write data. The evaluator shall run the application and attempt to store sensitive data. The evaluator shall then inspect those areas of the filesystem to note where data was stored (if any), and determine whether it has been encrypted.
If "leverage platform-provided functionality" is selected, the evaluation activities will be performed as stated in the following requirements, which vary on a per-platform basis.
MODE_PRIVATE flag set.
If “implement functionality to encrypt and store configuration options as defined by FDP_PRT_EXT.1 in the PP-Module for File Encryption" is selected, the TSF must claim conformance to a PP-Configuration that includes the PP-Module for File Encryption.
Conditional: If "implement functionality to encrypt and store configuration options as defined by FDP_PRT_EXT.1 in the PP-Module for File Encryption" is selected, the evaluator shall ensure that the TSS identifies those options, as well as indicates where the encrypted representation of these options is stored.
SharedPreferences and/or PreferenceActivity classes for storing configuration data, where package is the Java package of the application.
user defaults system or key-value store for storing all settings.
NSUserDefaults class.
find -L . -perm /002 inside the application's data directories to ensure that all files are not world-writable. The command should not print any files.
find -L . -perm /002 inside the application's data directories to ensure that all files are not world-writable. The command should not print any files.
find . \( -perm -002 \) inside the application's data directories to ensure that all files are not world-writable. The command should not print any files.
find . -perm +002 inside the application's data directories to ensure that all files are not world-writable. The command should not print any files.
A user-modifiable file for purposes of this requirement is a file that is writable by an unprivileged user of the application -- either directly through application execution or independently of the application. If the application runs in the context of the application user, then the application should not be able to write to the directory containing the application binaries -- regardless of whether the files are configuration data, audit data, or temporary files.
Executables and user-modifiable files may not share the same parent directory, but may share directories above the parent.
pmap -x PID to ensure the two different instances share no mapping locations.
pmap -x PID to ensure the two different instances share no mapping locations.
vmmap PID to ensure the two different instances share no mapping locations.
/NXCOMPAT flag was used during compilation to verify that DEP protections are enabled for the application.
If the OS platform supports the Enhanced Mitigation Experience Toolkit (EMET) which can be installed on Windows 10 version 1703 and earlier, then the evaluator shall ensure that the application can run successfully with EMET configured with the following minimum mitigations enabled; Memory Protection Check, Randomize memory allocations (Bottom-Up ASLR), Export address filtering (EAF), and Data Execution Prevention (DEP).
| mov rcx, QWORD PTR [rsp+(...)] |
| xor rcx, (...) |
| call (...) |
Tools such as Canary Detector may help automate these activities.
Valid SWID tags must contain a SoftwareIdentity element and an Entity element as defined in the ISO/IEC 19770-2:2015 standard. SWID tags must be stored with a .swidtag file extensions as defined in the ISO/IEC 19770-2:2015.
If "encrypt all transmitted" is selected and "TLS" is selected, then evaluation of elements from either FCS_TLSC_EXT.1 or FCS_TLSS_EXT.1 is required.
If "encrypt all transmitted" is selected, "HTTPS" is selected, and the TOE acts as a client, then FCS_HTTPS_EXT.1/Client is required.
If "encrypt all transmitted" is selected, "HTTPS" is selected, and the TOE acts as a server, then FCS_HTTPS_EXT.1/Server is required.
If the TOE acts as a server and if "mutual authentication" is selected in the TLS Package, then FCS_HTTPS_EXT.2 is also required.
If "encrypt all transmitted" is selected and "DTLS" is selected, then FCS_DTLS_EXT.1 is required.
If "encrypt all transmitted" is selected and "SSH" is selected, then the TSF shall be validated against the Functional Package for Secure Shell.
If "encrypt all transmitted" is selected and "IPsec" is selected, then the TSF must claim conformance to a PP-Configuration that includes the VPN Client PP-Module
If "encrypt all transmitted" is selected the corresponding FCS_COP.1 requirements will be included.
In addition to the above, FIA_X509_EXT.1 and FIA_X509_EXT.2 are required when the following is true:
If "implement DRBG functionality" is chosen, then additional FCS_RBG_EXT.2 elements shall be included in the ST.
In this requirement, cryptographic operations include all cryptographic key generation/derivation/agreement, IVs (for certain modes), as well as protocol-specific random values. Cryptographic operations in this requirement refer to the other cryptographic requirements in this PP, not additional functionality that is not in scope.
If "implement DRBG functionality" is selected, the evaluator shall ensure that additional FCS_RBG_EXT.2 elements are included in the ST.
If "invoke platform-provided DRBG functionality" is selected, the evaluator performs the following activities. The evaluator shall examine the TSS to confirm that it identifies all functions (as described by the SFRs included in the ST) that obtain random numbers from the platform RBG. The evaluator shall determine that for each of these functions, the TSS states which platform interface (API) is used to obtain the random numbers. The evaluator shall confirm that each of these interfaces corresponds to the acceptable interfaces listed for each platform below.
It should be noted that there is no expectation that the evaluators attempt to confirm that the APIs are being used correctly for the functions identified in the TSS; the activity is to list the used APIs and then do an existence check via decompilation.
The evaluator shall decompile the application binary using a decompiler suitable for the application (TOE). The evaluator shall search the output of the decompiler to determine that, for each API listed in the TSS, that API appears in the output. If the representation of the API does not correspond directly to the strings in the following list, the evaluator shall provide a mapping from the decompiled text to its corresponding API, with a description of why the API text does not directly correspond to the decompiled text and justification that the decompiled text corresponds to the associated API.
The following are the per-platform list of acceptable APIs:
javax.crypto.KeyGenerator class or the java.security.SecureRandom class or /dev/random or /dev/urandom.
SecRandomCopyBytes, CCRandomGenerateBytes, or CCRandomCopyBytes, or uses /dev/random directly to acquire random.
/dev/random or /dev/urandom.
/dev/random.
CCRandomGenerateBytes or CCRandomCopyBytes, or collects random from /dev/random.
KeyStore or the Android KeyChain to store certificates.
Keychain.
Key Management Framework (KMF).
Keychain.
uses-permission entry in the AndroidManifest.xml file for access to a hardware resource is reflected in the selection.
uses-permission entry in the AndroidManifest.xml file for access to a sensitive information repository is reflected in the selection.
Rule #3
Rule #8
A subset of the User Data Protection focuses on protecting Data-At-Rest, namely FDP_DAR_EXT.1 and FDP_DAR_EXT.2. Three levels of data-at-rest protection are addressed: TSF data, Protected Data (and keys), and sensitive data. Table 4 addresses the level of protection required for each level of data-at-rest.
Table 4: Protection of Data Levels
Rule #6
| # | Management Function | Impl. | User Only | Admin | Admin Only |
| 1 | configure password policy:
|
MMandatory
|
-N/A
|
MMandatory
|
MMandatory
|
| 2 | configure session locking policy:
|
MMandatory
|
-N/A
|
MMandatory
|
MMandatory
|
| 3 | enable/disable the VPN protection:
[selection:
|
MMandatory
|
OOptional
|
OOptional
|
OOptional
|
| 4 | enable/disable [assignment: list of all radios] |
MMandatory
|
OOptional
|
OOptional
|
OOptional
|
| 5 | enable/disable [assignment: list of audio or visual collection devices]:
[selection:
|
MMandatory
|
OOptional
|
OOptional
|
OOptional
|
| 6 | transition to the locked state |
MMandatory
|
-N/A
|
MMandatory
|
-N/A
|
| 7 | TSF wipe of protected data |
MMandatory
|
-N/A
|
MMandatory
|
-N/A
|
| 8 | configure application installation policy by
[selection:
|
MMandatory
|
-N/A
|
MMandatory
|
MMandatory
|
| 9 | import keys or secrets into the secure key storage |
MMandatory
|
OOptional
|
OOptional
|
-N/A
|
| 10 | destroy imported keys or secrets and [selection: no other keys or secrets, [assignment: list of other categories of keys or secrets]] in the secure key storage |
MMandatory
|
OOptional
|
OOptional
|
-N/A
|
| 11 | import X.509v3 certificates into the Trust Anchor Database |
MMandatory
|
-N/A
|
MMandatory
|
OOptional
|
| 12 | remove imported X.509v3 certificates and [selection: no other X.509v3 certificates, [assignment: list of other categories of X.509v3 certificates]] in the Trust Anchor Database |
MMandatory
|
OOptional
|
OOptional
|
-N/A
|
| 13 | enroll the TOE in management |
MMandatory
|
OOptional
|
OOptional
|
OOptional
|
| 14 | remove applications |
MMandatory
|
-N/A
|
MMandatory
|
OOptional
|
| 15 | update system software |
MMandatory
|
-N/A
|
MMandatory
|
OOptional
|
| 16 | install applications |
MMandatory
|
-N/A
|
MMandatory
|
OOptional
|
| 17 | remove Enterprise applications |
MMandatory
|
-N/A
|
MMandatory
|
-N/A
|
| 18 | enable/disable display notification in the locked state of: [selection:
|
MMandatory
|
OOptional
|
OOptional
|
OOptional
|
| 19 | enable data-at rest protection |
MMandatory
|
OOptional
|
OOptional
|
OOptional
|
| 20 | enable removable media’s data-at-rest protection |
MMandatory
|
OOptional
|
OOptional
|
OOptional
|
| 21 | enable/disable location services:
[selection:
|
MMandatory
|
OOptional
|
OOptional
|
OOptional
|
| 22 | enable/disable the use of [selection: Biometric Authentication Factor, Hybrid Authentication Factor] |
OOptional
|
OOptional
|
OOptional
|
OOptional
|
| 23 | configure whether to allow or disallow establishment of [assignment: configurable trusted channel in FTP_ITC_EXT.1.1 or FDP_UPC_EXT.1.1/APPS] if the peer or server certificate is deemed invalid. |
OOptional
|
OOptional
|
OOptional
|
OOptional
|
| 24 | enable/disable all data signaling over [assignment: list of externally accessible hardware ports] |
OOptional
|
OOptional
|
OOptional
|
OOptional
|
| 25 | enable/disable [assignment: list of protocols where the device acts as a server] |
OOptional
|
OOptional
|
OOptional
|
OOptional
|
| 26 | enable/disable developer modes |
OOptional
|
OOptional
|
OOptional
|
OOptional
|
| 27 | enable/disable bypass of local user authentication |
OOptional
|
OOptional
|
OOptional
|
OOptional
|
| 28 | wipe Enterprise data |
OOptional
|
OOptional
|
OOptional
|
-N/A
|
| 29 | approve [selection: import, removal] by applications of X.509v3 certificates in the Trust Anchor Database |
OOptional
|
OOptional
|
OOptional
|
OOptional
|
| 30 | configure whether to allow or disallow establishment of a trusted channel if the TSF cannot establish a connection to determine the validity of a certificate |
OOptional
|
OOptional
|
OOptional
|
OOptional
|
| 31 | enable/disable the cellular protocols used to connect to cellular network base stations |
OOptional
|
OOptional
|
OOptional
|
OOptional
|
| 32 | read audit logs kept by the TSF |
OOptional
|
OOptional
|
OOptional
|
-N/A
|
| 33 | configure [selection: certificate, public-key] used to validate digital signature on applications |
OOptional
|
OOptional
|
OOptional
|
OOptional
|
| 34 | approve exceptions for shared use of keys or secrets by multiple applications |
OOptional
|
OOptional
|
OOptional
|
OOptional
|
| 35 | approve exceptions for destruction of keys or secrets by applications that did not import the key or secret |
OOptional
|
OOptional
|
OOptional
|
OOptional
|
| 36 | configure the unlock banner |
MMandatory
|
-N/A
|
OOptional
|
OOptional
|
| 37 | configure the auditable items |
OOptional
|
-N/A
|
OOptional
|
OOptional
|
| 38 | retrieve TSF-software integrity verification values |
OOptional
|
OOptional
|
OOptional
|
OOptional
|
| 39 | enable/disable [selection:
|
OOptional
|
OOptional
|
OOptional
|
OOptional
|
| 40 | enable/disable backup of [selection: all applications, selected applications, selected groups of applications, configuration data] to [selection: locally connected system, remote system] |
OOptional
|
OOptional
|
OOptional
|
OOptional
|
| 41 | enable/disable [selection:
|
OOptional
|
OOptional
|
OOptional
|
OOptional
|
| 42 | approve exceptions for sharing data between [selection: applications, groups of applications] |
OOptional
|
OOptional
|
OOptional
|
OOptional
|
| 43 | place applications into application groups based on [assignment: enterprise configuration settings] |
OOptional
|
OOptional
|
OOptional
|
OOptional
|
| 44 | unenroll the TOE from management |
OOptional
|
OOptional
|
OOptional
|
OOptional
|
| 45 | enable/disable the Always On VPN protection:
[selection:
|
OOptional
|
OOptional
|
OOptional
|
OOptional
|
| 46 | revoke Biometric template |
OOptional
|
OOptional
|
OOptional
|
OOptional
|
| 47 | [assignment: list of other management functions to be provided by the TSF] |
OOptional
|
OOptional
|
OOptional
|
OOptional
|
Functions 3 , 5 , and 21 must be implemented on a device-wide basis but may also be implemented on a per-app basis or on a per-group of applications basis in which the configuration includes the list of applications or groups of applications to which the enable/disable applies.
Function 3 addresses enabling and disabling the IPsec VPN only. The configuration of the VPN Client itself (with information such as VPN Gateway, certificates, and algorithms) is addressed by the PP-Module for Virtual Private Network (VPN) Clients, version 2.4. The administrator options should only be listed if the administrator can remotely enable/disable the VPN connection.
Function 3 optionally allows the VPN to be configured per-app or per-groups of apps. If this configuration is selected, it does not void FDP_IFC_EXT.1. Instead FDP_IFC_EXT.1 is applied to the application or group of applications the VPN is applied to. In other words, all traffic destined for the VPN-enabled application or group of applications, must travel through the VPN, but traffic not destined for that application or group of applications can travel outside the VPN. When the VPN is configured across the device FDP_IFC_EXT.1 applies to all traffic and the VPN must not split tunnel.
The assignment in function 4 consists of all radios present on the TSF, such as Wi-Fi, cellular, NFC, Bluetooth BR/EDR, and Bluetooth LE, which can be enabled and disabled. In the future, if both Bluetooth BR/EDR and Bluetooth LE are supported, they will be required to be enabled and disabled separately. Disablement of the cellular radio does not imply that the radio may not be enabled in order to place emergency phone calls; however, it is not expected that a device in "airplane mode", where all radios are disabled, will automatically (without authorization) turn on the cellular radio to place emergency calls.
The assignment in function 5 consists of at least one audio or visual device, such as camera and microphone, which can be enabled and disabled by either the user or administrator. Disablement of the microphone does not imply that the microphone may not be enabled in order to place emergency phone calls. If certain devices are able to be restricted to the enterprise (either device-wide, per-app or per-group of applications) and others are able to be restricted to users, then this function should be iterated in the table with the appropriate table entries.
Regarding functions 4 and 5, disablement of a particular radio or audio/visual device must be effective as soon as the TOE has power. Disablement must also apply when the TOE is booted into auxiliary boot modes, for example, associated with updates or backup. If the TOE supports states in which security management policy is inaccessible, for example, due to data-at-rest protection, it is acceptable to meet this requirement by ensuring that these devices are disabled by default while in these states. That these devices are disabled during auxiliary boot modes does not imply that the device (particularly the cellular radio) may not be enabled in order to perform emergency phone calls.
Wipe of the TSF (function 7) is performed according to FCS_CKM_EXT.5. Protected data is all non-TSF data, including all user or enterprise data. Some or all of this data may be considered sensitive data as well.
The selection in function 8 allows the ST author to select which mechanisms are available to the administrator through the MDM Agent to restrict the applications which the user may install. The ST author must state if application allowlist is applied device-wide or if it can be specified to apply to either the Enterprise or Personal applications.
In the future, function 12 may require destruction or disabling of any default trusted CA certificates, excepting those CA certificates necessary for continued operation of the TSF, such as the developer’s certificate. At this time, the ST author must indicate in the assignment whether pre-installed or any other category of X.509v3 certificates may be removed from the Trust Anchor Database.
For function 13, the enrollment function may be installing an MDM agent and includes the policies to be applied to the device. It is acceptable for the user approval notice to require the user to intentionally opt to view the policies (for example, by "tapping" on a "View" icon) rather than listing the policies in full in the notice.
For function 15, the administrator capability to update the system software may be limited to causing a prompt to the user to update rather than the ability to initiate the update itself. As the administrator is likely to be acting remotely, he/she would be unaware of inopportune situations, such as low power, which may cause the update to fail and the device to become inoperable. The user can refuse to accept the update in such situations. It is expected that system architects will be cognizant of this limitation and will enforce network access controls in order to enforce enterprise-critical updates.
Function 16 addresses both installation and update. This protection profile does not distinguish between installation and update of applications because mobile devices typically completely overwrite the previous installation with a new installation during an application update.
For function 17, "Enterprise applications" are those applications that belong to the Enterprise application group. Applications installed by the enterprise administrator (including automatic installation by the administrator after being requested by the user from a catalog of enterprise applications) are by default placed in the Enterprise application group unless an exception has been made in function 43 of FMT_SMF.1.1.
If the display of notifications in the locked state is supported, the configuration of these notifications (function 18) must be included in the selection.
Function 19 must be included in the selection if data-at-rest protection is not natively enabled.
Function 20 is implicitly met if the TSF does not support removable media.
For function 21, location services include location information gathered from GPS, cellular, and Wi-Fi.
Function 22 must be included in the ST if the TOE contains a BAF. This selection must correspond with the selection made in FIA_UAU.5.1. If biometric in accordance with the Biometric Enrollment and Verification, version 1.1 is selected in FIA_UAU.5.1, "Biometric Authentication Factor" must be selected and the user or admin must have the option to disable the use of it. If multiple BAFs are claimed in FIA_MBV_EXT.1.1 in the Biometric Enrollment and Verification, version 1.1, this applies to all different modalities. If hybrid is selected in FIA_UAU.5.1 it must be selected and the user or admin must have the option to disable the use of it.
Function 23 must be included in the ST if the function is configurable on the TOE for any of the trusted channels either mandated or selected in FTP_ITC_EXT.1.1 or FDP_UPC_EXT.1.1/APPS. The configuration can be different depending on the specific trusted channel(s) and they must be filled in for the assignment.
The assignment in function 24 consists of all externally accessible hardware ports, such as USB, the SD card, and HDMI, whose data transfer capabilities can be enabled and disabled by either the user or administrator. Disablement of data transfer over an external port must be effective during and after boot into the normal operative mode of the device. If the TOE supports states in which configured security management policy is inaccessible, for example, due to data-at-rest protection, it is acceptable to meet this requirement by ensuring that data transfer is disabled by default while in these states. Each of the ports may be enabled or disabled separately. The configuration policy need not disable all ports together. In the case of USB, charging is still allowed if data transfer capabilities have been disabled.
The assignment in function 25 consists of all protocols where the TSF acts as a server, which can be enabled and disabled by either the user or administrator.
Function 26 must be included in the selection if developer modes are supported by the TSF.
Function 27 must be included in the selection if bypass of local user authentication, such as a "Forgot Password", password hint, or remote authentication feature, is supported.
Function 29 must be included in the selection if the TSF allows applications, other than the MDM Agents, to import or remove X.509v3 certificates from the Trust Anchor Database. The MDM Agent is considered the administrator. This function does not apply to applications trusting a certificate for its own validations. The function only applies to situations where the application modifies the device-wide Trust Anchor Database, affecting the validations performed by the TSF for other applications. The user or administrator may be provided the ability to globally allow or deny any application requests in order to meet this requirement.
Function 30 must be included in the ST if "administrator-configured option" is selection in FIA_X509_EXT.2.2.
Function 33 should be included in the selection if FPT_TUD_EXT.5.1 is included in the ST and the configurable option is selected.
Function 34 should be included in the selection if user or administrator is selected in FCS_STG_EXT.1.4.
Function 35 should be included in the selection if the user or the administrator is selected in FCS_STG_EXT.1.5.
Function 37 must be included in the selection if FAU_SEL.1 is included in the ST.
For function 41, hotspot functionality refers to the condition in which the mobile device is serving as an access point to other devices, not the connection of the TOE to external hotspots.
Functions 42 and 43 correspond to FDP_ACF_EXT.1.2.
For function 44, FMT_SMF_EXT.2.1 specifies actions to be performed when the TOE is unenrolled from management.
Function 45 must be included in the ST if IPsec is selected in FTP_ITC_EXT.1 and the native IPsec VPN client can be configured to be Always-On. Always-On is defined as when the TOE has a network connection the VPN attempts to connect, all data leaving the device uses the VPN when the VPN is connected and no data leaves that device when the VPN is disconnected. The configuration of the VPN Client itself (with information such as VPN Gateway, certificates, and algorithms) is addressed by the PP-Module for Virtual Private Network (VPN) Clients, version 2.4.
Rule #6
Rule #7
Rule #8
Rule #11
The following rationale provides justification for each security objective for the TOE, showing that the SFRs are suitable to meet and achieve the security objectives:
| Objective | Addressed by | Rationale | |
|---|---|---|---|
| O. | INTEGRITYAUTH
| FDPFIA_DECAFL_EXT.1The PP includes FDP_DEC | FIA_AFL_EXT.1 to limit access to platform hardware resources, which limits the methods by which an attacker can attempt to compromise the integrity of the TOE. |
| supports the objective by defining the authentication mechanisms that are subject to lockout behavior and how the TSF handles repeated failed authentication attempts. | |||
| FIA_PMG_EXT.1The PP | includes FMT_CFGFIA_PMG_EXT.1 supports the objective by defining the minimum quality threshold for the TSP to limit unauthorized access to itself by preventing the use of default authentication credentials and by ensuring that the TOE uses appropriately restrictive platform permissions on its binaries and data | ||
| FPT_AEX_EXT.1 | The PP includes FPT_AEX_EXT.1 to add complexity to the task of compromising systems by ensuring that application is compatible with security features provided by the platform vendor and that the application implements platform-provided anti-exploitations such as ASLR and stack overflow protection. | ||
| FPT_TUD_EXT.1 | The PP includes FPT_TUD_EXT.1 to ensure that the TOE can be patched and that any updates to the TOE have appropriate integrity protection. | ||
| O.QUALITY
| FCS_CKM.1 | The PP supports this objective by allowing FCS_CKM_EXT.1 to specify that the TSF may rely on platform-provided key generation services. | |
| FCS_RBG_EXT.1 | The PP supports this objective by allowing FCS_RBG_EXT.1 to specify that the TSF may rely on platform-provided random bit generation services. | ||
| FCS_STO_EXT.1 | The PP supports this objective by allowing FCS_STO_EXT.1 to specify that the TSF may rely on platform-provided credential storage services. | ||
| FDP_DAR_EXT.1 | The PP supports this objective by allowing FDP_DAR_EXT.1 to specify that the TSF may rely on platform-provided data-at-rest protection services. | ||
| FMT_MEC_EXT.1 | The PP includes FMT_MEC_EXT.1 to ensure that the TOE can use platform services to store and set configuration options. | ||
| FPT_API_EXT.1 | The PP includes FPT_API_EXT.1 to require the TOE to leverage platform functionality by using only documented and supported APIs. | ||
| FPT_LIB_EXT.1 | The PP includes FPT_LIB_EXT.1 to ensure that the TOE does not include any unnecessary or unexpected third-party libraries which could present a privacy threat or vulnerability. | ||
| FTP_DIT_EXT.1 | The PP supports this objective by allowing FTP_DIT_EXT.1 to specify that the TSF may rely on platform-provided services to implement trusted communications. | ||
| FCS_CKM.1/AK (selection-based) | The PP supports this objective by allowing FCS_CKM.1/AK to specify that the TSF may rely on platform-provided asymmetric key generation services. | ||
| FCS_CKM.2 (selection-based) | The PP supports this objective by allowing FCS_CKM.2 to specify that the TSF may rely on platform-provided key establishment services. | ||
| FIA_X509_EXT.1 (selection-based) | The PP supports this objective by allowing FIA_X509_EXT.1 to specify that the TSF may rely on platform-provided X.509 certificate validation services. | ||
| FPT_TUD_EXT.2 (selection-based) | The TSF includes FPT_TUD_EXT.2 to specify that the TOE may leverage the platform-supported package manager for application distribution and leverages platform-provided mechanisms to remove all traces of itself when removed from the platform system. | ||
| FPT_API_EXT.2 (objective) | The PP includes FPT_API_EXT.2 to permit the TOE to use platform-provided libraries for parsing IANA MIME media formats. | ||
| O.MANAGEMENT
| FMT_SMF.1 | The PP includes FMT_SMF.1 to define the security-relevant management functions that are supported by the TOE. | |
| FPR_ANO_EXT.1 | The PP includes FPR_ANO_EXT.1 to define how the TSF provides control to the user regarding the disclosure of any PII. | ||
| FPT_IDV_EXT.1 | The PP includes FPT_IDV_EXT.1 to provide a methodology for identifying the TOE versioning. | ||
| FPT_TUD_EXT.1 | The PP includes FPT_TUD_EXT.1 to define how updates to the TOE are deployed and verified. | ||
| FCS_COP.1/Sig | The PP includes FCS_COP.1/Sig to define the mechanism used to verify TOE updates if the TOE implements this functionality rather than the underlying platform. | ||
| O.PROTECTED_STORAGE
| FCS_RBG_EXT.1 | The PP includes FCS_RBG_EXT.1 to define whether random bit generation services are implemented by the TSF or the platform. Depending on how data at rest is protected, the TOE may rely on the use of a random bit generator to create keys that are subsequently used for data protection. | |
| FCS_STO_EXT.1 | The PP includes FCS_STO_EXT.1 to define the mechanism that the TSF uses or relies upon to protect stored credential data. | ||
| FDP_DAR_EXT.1 | The PP includes FDP_DAR_EXT.1 to define the mechanism that the TSF uses or relies upon to protect sensitive data at rest. | ||
| FCS_CKM.1/SK (optional) | The PP includes FCS_CKM.1/SK to define the TOE’s capability to generate symmetric keys. These keys may subsequently be used to encrypt stored credential data based on the claims made in FCS_STO_EXT.1. | ||
| FCS_CKM.1/PBKDF (selection-based) | The PP includes FCS_CKM.1/PBKDF to define the password-based key derivation function that may be used to encrypt stored credential data based on the claims made in FCS_STO_EXT.1. | ||
| FCS_COP.1/SKC (selection-based) | The PP includes FCS_COP.1/SKC to define the AES cryptographic algorithm that may be used to encrypt stored credential data based on the claims made in FCS_STO_EXT.1. | ||
| FCS_COP.1/Hash (selection-based) | The PP includes FCS_COP.1/Hash to define integrity mechanisms that may be used by the TOE as part of ensuring that data at rest is protected. | ||
| FCS_COP.1/KeyedHash (selection-based) | The PP includes FCS_COP.1/KeyedHash to define HMAC mechanisms that may be used by the TOE as part of ensuring that data at rest is protected. | ||
| FCS_RBG_EXT.2 (selection-based) | The PP includes FCS_RBG_EXT.2 to define the TOE’s implementation of random bit generation functionality in the event that the TOE provides this function in support of generating keys that are used for data protection. | ||
| O.PROTECTED_COMMS
| FCS_RBG_EXT.1 | The PP includes FCS_RBG_EXT.1 to define whether the random bit generation services used in establishing trusted communications are implemented by the TSF or by the platform. | |
| FCS_CKM.1 | The PP includes FCS_CKM_EXT.1 to specify whether the TOE or the platform is responsible for generation of any asymmetric keys that may be used for establishing trusted communications. | ||
| FTP_DIT_EXT.1 | The PP includes FTP_DIT_EXT.1 to define the trusted channels used to protect data in transit, the data that is protected, and whether the trusted channels are implemented by the TSF or the platform. | ||
| FCS_CKM.1/AK | The PP includes FCS_CKM.1/AK to define whether the TSF or the platform generates asymmetric keys that are used in support of trusted communications. | ||
| FCS_CKM.2 | The PP includes FCS_CKM.2 to define whether the TSF or the platform performs key establishment for trusted communications. | ||
| FCS_COP.1/SKC | The PP includes FCS_COP.1/SKC to define the symmetric encryption algorithms used in support of trusted communications. | ||
| FCS_COP.1/Hash | The PP includes FCS_COP.1/Hash to define the hash algorithms used in support of trusted communications. | ||
| FCS_COP.1/Sig | The PP includes FCS_COP.1/Sig to define the digital signature algorithms used in support of trusted communications. | ||
| FCS_COP.1/KeyedHash | The PP includes FCS_COP.1/KeyedHash to define the HMAC algorithms used in support of trusted communications. | ||
| FCS_RBG_EXT.2 | The PP includes FCS_RBG_EXT.2 to define the DRBG algorithms used in support of trusted communications. | ||
| FCS_HTTPS_EXT.1/Client | The PP includes FCS_HTTPS_EXT.1 to define the TOE’s support for the HTTPS trusted communications protocol as a client. | ||
| FCS_HTTPS_EXT.1/Server | The PP includes FCS_HTTPS_EXT.1 to define the TOE’s support for the HTTPS trusted communications protocol as a server. | ||
| FDP_NET_EXT.1 | The PP includes FDP_NET_EXT.1 to define the TOE’s usage of network communications, which may include the transmission or receipt of data over a trusted channel. | ||
| FIA_X509_EXT.1 | The PP includes FIA_X509_EXT.1 to define X.509 certificate validation activities in support of trusted communications. | ||
| FIA_X509_EXT.2 | The PP includes FIA_X509_EXT.2 to define the trusted communications that X.509 certificate services support, as well as the extent to which trusted communications can be established when using a certificate with unknown validitypasswords that the TSF must enforce. | ||
| FIA_TRT_EXT.1 | FIA_TRT_EXT.1 supports the objective by enforcing an authentication throttling mechanism that limits the rate at which authentication attempts can be made to the TOE. | ||
| FIA_UAU.5 | FIA_UAU.5 supports the objective by defining all authentication factors the TSF supports and rules for how these authentication factors are used to gain access to the TSF. | ||
| FIA_UAU.6/CREDENTIAL | FIA_UAU.6/CREDENTIAL supports the objective by requiring the TSF to re-authenticate users with their password prior to allowing them to change any other authentication data. | ||
| FIA_UAU.6/LOCKED | FIA_UAU.6/LOCKED supports the objective by requiring the TSF to re-authenticate users with a valid credential prior to allowing a locked device to be unlocked. | ||
| FIA_UAU.7 | FIA_UAU.7 supports the objective by ensuring that TSF does not disclose user authentication data as it is being input to the TOE. | ||
| FIA_UAU_EXT.1 | FIA_UAU_EXT.1 supports the objective by requiring the TSF to be provided with a valid password before access to protected data is granted. | ||
| FIA_UAU_EXT.2 | FIA_UAU_EXT.2 supports the objective by defining the TOE functions that can be accessed without authentication such that all other services require authentication. | ||
| FIA_UAU_EXT.4 | FIA_UAU_EXT.4 supports the objective by defining a secondary authentication mechanism for Enterprise resources. | ||
| FIA_X509_EXT.2 | FIA_X509_EXT.2 supports the objective by defining the functions for which the TSF uses X.509 certificates as an authentication mechanism. | ||
| FTA_SSL_EXT.1 | FTA_SSL_EXT.1 supports the objective by requiring the TSF to ensure that an idle user session is terminated after a given period of time. | ||
| O.CONFIG
| FMT_MOF_EXT.1 | FMT_MOF_EXT.1 supports the objective by specifying the TSF management functions that an end user is authorized to perform. | |
| FMT_SMF.1 | FMT_SMF.1 supports the objective by defining the TSF management functions and the users or roles that are authorized to invoke them. | ||
| FMT_SMF_EXT.2 | FMT_SMF_EXT.2 supports the objective by defining the configuration actions that the TSF performs automatically upon unenrollment from mobile device management. | ||
| FTA_TAB.1 | FTA_TAB.1 supports the objective by requiring the TSF to display a warning banner to users that governs authorized usage of the TOE. | ||
| O.INTEGRITY
| FAU_GEN.1 | FAU_GEN.1 supports the objective by requiring the TSF to record actions performed against it to establish a record of potential malicious activity. | |
| FAU_SAR.1 | FAU_SAR.1 supports the objective by requiring the TSF to provide a mechanism to review the stored audit data so administrators can diagnose the root cause of malicious usage. | ||
| FAU_SEL.1 | FAU_SEL.1 supports the objective by allowing the TSF to restrict the audit records that are generated so that records unrelated to potential malicious usage can be suppressed. | ||
| FAU_STG.1 | FAU_STG.1 supports the objective by ensuring that a malicious user cannot tamper with audit records by modifying or deleting them. | ||
| FAU_STG.4 | FAU_STG.4 supports the objective by ensuring the availability of audit records. | ||
| FCS_COP.1/HASH | FCS_COP.1/HASH supports the objective by requiring the TSF to implement hash algorithms that can be used to assert and verify integrity. | ||
| FCS_COP.1/SIGN | FCS_COP.1/SIGN supports the objective by requiring the TSF to implement digital signature algorithms that can be used to assert and verify integrity. | ||
| FDP_ACF_EXT.1 | FDP_ACF_EXT.1 supports the objective by requiring the TSF to maintain the integrity of its system services by limiting the entities that can access them. | ||
| FDP_ACF_EXT.3 | FDP_ACF_EXT.3 supports the objective by requiring the TSF to ensure that writable files cannot be executed and vice versa, such that arbitrary code or scripts cannot be executed to compromise the integrity of the TOE. | ||
| FPT_AEX_EXT.1 | FPT_AEX_EXT.1 supports the objective by requiring the TSF to implement ASLR to prevent a compromise of the TSF. | ||
| FPT_AEX_EXT.2 | FPT_AEX_EXT.2 supports the objective by requiring the TSF to enforce permissions against memory pages to prevent a compromise of the TSF. | ||
| FPT_AEX_EXT.3 | FPT_AEX_EXT.3 supports the objective by requiring the TSF to implement stack overflow protection to prevent a compromise of the TSF. | ||
| FPT_AEX_EXT.4 | FPT_AEX_EXT.4 supports the objective by requiring the TSF to enforce address space separation to prevent a compromise of the TSF. | ||
| FPT_AEX_EXT.5 | FPT_AEX_EXT.5 supports the objective by requiring the TSF to implement ASLR to prevent a compromise of the TSF. | ||
| FPT_AEX_EXT.6 | FPT_AEX_EXT.6 supports the objective by requiring the TSF to ensure that writable files cannot be executed and vice versa, such that arbitrary code or scripts cannot be executed to compromise the integrity of the TOE. | ||
| FPT_AEX_EXT.7 | FPT_AEX_EXT.7 supports the objective by requiring the TSF to implement heap overflow protection to prevent a compromise of the TSF. | ||
| FPT_BBD_EXT.1 | FPT_BBD_EXT.1 supports the objective by ensuring that isolation between the TOE's baseband processor and application processor is enforced so that access to the baseband processor is strictly controlled. | ||
| FPT_NOT_EXT.1 | FPT_NOT_EXT.1 supports the objective by requiring the TSF to take some action to prevent its integrity in the event of various failure conditions. | ||
| FPT_NOT_EXT.2 | FPT_NOT_EXT.2 supports the objective by requiring the TSF to make its integrity verification values available for the purpose of remote attestation. | ||
| FPT_STM.1 | FPT_STM.1 supports the objective by ensuring accurate system time data is applied to audit logs. | ||
| FPT_TST_EXT.1 | FPT_TST_EXT.1 supports the objective by defining the self-tests that the TSF performs to validate its own integrity. | ||
| FPT_TST_EXT.2/POSTKERNEL | FPT_TST_EXT.2/POSTKERNEL supports the objective by requiring the TSF to verify the integrity of stored executable code prior to its execution. | ||
| FPT_TST_EXT.2/PREKERNEL | FPT_TST_EXT.2/PREKERNEL supports the objective by requiring the TSF to verify the integrity of its bootchain prior to kernel load. | ||
| FPT_TST_EXT.3 | FPT_TST_EXT.3 supports the objective by requiring the TSF to block code execution if its code signing certificate is invalid. | ||
| FPT_TUD_EXT.1 | FPT_TUD_EXT.1 supports the objective by allowing users to determine the version of the TOE's hardware, software/firmware, and installed applications. | ||
| FPT_TUD_EXT.2 | FPT_TUD_EXT.2 supports the objective by requiring the TSF to validate the integrity of software updates prior to installing them. | ||
| FPT_TUD_EXT.3 | FPT_TUD_EXT.3 supports the objective by requiring the TSF to validate the integrity of third-party applications prior to installing them. | ||
| FPT_TUD_EXT.4 | FPT_TUD_EXT.4 supports the objective by requiring the TSF to block installation of code if its associated code signing certificate is invalid. | ||
| FPT_TUD_EXT.5 | FPT_TUD_EXT.5 supports the objective by specifying the X.509 certificate that the TSF uses to verify applications prior to their installation. | ||
| FPT_TUD_EXT.6 | FPT_TUD_EXT.6 supports the objective by preventing the TSF from being rolled back to an earlier version that may have known vulnerabilities that were subsequently patched. | ||
| O.PRIVACY
| FDP_ACF_EXT.1 | FDP_ACF_EXT.1 supports the objective by enforcing restrictions on services that could compromise user privacy if accessed inappropriately. | |
| FDP_ACF_EXT.2 | FDP_ACF_EXT.2 supports the objective by requiring the TSF to provide separate user data stores for application groups so that the privacy of that data can be maintained. | ||
| FDP_BCK_EXT.1 | FDP_BCK_EXT.1 supports the objective by allowing data to be excluded from backup operations that could compromise user privacy if disclosed. | ||
| FMT_SMF.1 | FMT_SMF.1 supports the objective by requiring the TSF to implement management functions that control the extent to which user data is collected and disseminated. | ||
| FMT_SMF_EXT.3 | FMT_SMF_EXT.3 supports the objective by requiring the TSF to identify its authorized administrators so that a user knows the extent to which various administrators have access to the device. | ||
| O.PROTECTED_​COMMS
| FCS_CKM.1 | FCS_CKM.1 supports the objective by defining the key generation algorithms that are used for protected communications. | |
| FCS_CKM.2/UNLOCKED | FCS_CKM.2/UNLOCKED supports the objective by defining the key establishment algorithms that are used for protected communications. | ||
| FCS_COP.1/ENCRYPT | FCS_COP.1/ENCRYPT supports the objective by requiring the TSF to implement symmetric encryption algorithms that are used in support of protected communications. | ||
| FCS_COP.1/HASH | FCS_COP.1/HASH supports the objective by requiring the TSF to implement hash algorithms that are used in support of protected communications. | ||
| FCS_COP.1/KEYHMAC | FCS_COP.1/KEYHMAC supports the objective by requiring the TSF to implement HMAC algorithms that are used in support of protected communications. | ||
| FCS_COP.1/SIGN | FCS_COP.1/SIGN supports the objective by requiring the TSF to implement digital signature algorithms that are used in support of protected communications. | ||
| FCS_HTTPS_EXT.1 | FCS_HTTPS_EXT.1 supports the objective by defining the TOE's implementation of HTTPS if this protocol is used for protected communications. | ||
| FCS_RBG_EXT.1 | FCS_RBG_EXT.1 supports the objective by requiring the TSF to implement deterministic random bit generation algorithms that are used in support of protected communications. | ||
| FCS_RBG_EXT.2 | FCS_RBG_EXT.2 supports the objective by requiring the TSF to save the DRBG state between reboots to ensure availability of this service. | ||
| FCS_RBG_EXT.3 | FCS_RBG_EXT.3 supports the objective by defining the TSF's implementation of the SP 800-90A Personalization String for applications that require this. | ||
| FCS_SRV_EXT.1 | FCS_SRV_EXT.1 supports the objective by defining the cryptographic services that the TSF must make available to third-party applications, which includes those that can support protected communications. | ||
| FCS_SRV_EXT.2 | FCS_SRV_EXT.2 supports the objective by requiring the TSF to make keys in its secure key storage available for use in encryption and signing operations. | ||
| FDP_BLT_EXT.1 | FDP_BLT_EXT.1 supports the objective by limiting the applications that are authorized to use the Bluetooth interface, which may include a trusted channel. | ||
| FDP_IFC_EXT.1 | FDP_IFC_EXT.1 supports the objective by requiring the TSF to have either its own IPsec VPN client or interface that allows a third-party VPN client to be deployed on it. | ||
| FDP_STG_EXT.1 | FDP_STG_EXT.1 supports the objective by requiring the TSF to implement a protected key storage that can be used to protect persistent keys used for protected communications from disclosure. | ||
| FDP_UPC_EXT.1/APPS | FDP_UPC_EXT.1/APPS supports the objective by defining the protected communications channels that it allows third-party applications to invoke. | ||
| FDP_UPC_EXT.1/BLUETOOTH | FDP_UPC_EXT.1/BLUETOOTH supports the objective by defining the Bluetooth interfaces that it allows third-party applications to invoke. | ||
| FIA_X509_EXT.1 | FIA_X509_EXT.1 supports the objective by defining the rules the TSF uses to determine if a presented X.509 certificate is valid. | ||
| FIA_X509_EXT.2 | FIA_X509_EXT.2 supports the objective by requiring the TSF to enumerate its uses of X.509 certificates (including protected communications) and its behavior when a certificate's revocation status is undetermined. | ||
| FIA_X509_EXT.3 | FIA_X509_EXT.3 supports the objective by requiring the TSF to provide a certificate validation service to third-party applications. | ||
| FIA_X509_EXT.4 | FIA_X509_EXT.4 supports the objective by defining the implementation of EST as a method by which the TSF can obtain an X.509 certificate for its own use. | ||
| FIA_X509_EXT.5 | FIA_X509_EXT.5 supports the objective by defining the implementation of Certificate Request Messages as a method by which the TSF can obtain an X.509 certificate for its own use. | ||
| FPT_BLT_EXT.1 | FPT_BLT_EXT.1 supports the objective by requiring the TSF to disable certain Bluetooth profiles when they are inactive such that explicit user authorization is required to re-enable them. | ||
| O.STORAGE
| FCS_CKM.2/LOCKED | FCS_CKM.2/LOCKED supports the objective by defining the key establishment mechanism used for keys that protect data at rest when the TOE is in a locked state. | |
| FCS_CKM_EXT.1 | FCS_CKM_EXT.1 supports the objective by defining the TOE's root encryption key that is used to protect data at rest. | ||
| FCS_CKM_EXT.2 | FCS_CKM_EXT.2 supports the objective by defining how the TSF creates data encryption keys that are used to protect data at rest. | ||
| FCS_CKM_EXT.3 | FCS_CKM_EXT.3 supports the objective by defining the key encryption keys the TOE uses to protect data at rest and how they are created. | ||
| FCS_CKM_EXT.4 | FCS_CKM_EXT.4 supports the objective by requiring the TSF to destroy keys and key material that could otherwise be used to compromise data at rest. | ||
| FCS_CKM_EXT.5 | FCS_CKM_EXT.5 supports the objective by defining the mechanism the TSF uses to perform a wipe operation that securely destroys data at rest. | ||
| FCS_CKM_EXT.6 | FCS_CKM_EXT.6 supports the objective by requiring the TSF to use secure salts when performing cryptographic operations that require them. | ||
| FCS_CKM_EXT.7 | FCS_CKM_EXT.7 supports the objective by ensuring that the TOE's root encryption key cannot be disclosed. | ||
| FCS_COP.1/CONDITION | FCS_COP.1/CONDITION supports the objective by defining a key derivation function that can be used to protect data at rest. | ||
| FCS_COP.1/ENCRYPT | FCS_COP.1/ENCRYPT supports the objective by defining a symmetric encryption/decryption function that can be used to protect data at rest. | ||
| FCS_COP.1/HASH | FCS_COP.1/HASH supports the objective by defining a hash function that can be used to protect data at rest. | ||
| FCS_COP.1/KEYHMAC | FCS_COP.1/KEYHMAC supports the objective by defining an HMAC function that can be used to protect data at rest. | ||
| FCS_COP.1/SIGN | FCS_COP.1/SIGN supports the objective by defining a digital signature function that can be used to protect data at rest. | ||
| FCS_IV_EXT.1 | FCS_IV_EXT.1 supports the objective by ensuring that any IVs the TSF generates for AES keys are generated in an appropriate manner based on the relevant standards. | ||
| FCS_RBG_EXT.1 | FCS_RBG_EXT.1 supports the objective by defining random bit generation function that can be used to protect data at rest. | ||
| FCS_STG_EXT.1 | FCS_STG_EXT.1 supports the objective by requiring the TSF to implement a hardware or software key store to protect key data at rest. | ||
| FCS_STG_EXT.2 | FCS_STG_EXT.2 supports the objective by defining the confidentiality mechanism used to protect stored key data from unauthorized disclosure. | ||
| FCS_STG_EXT.3 | FCS_STG_EXT.3 supports the objective by defining the integrity mechanism used to protect stored key data from unauthorized modification. | ||
| FDP_ACF_EXT.3 | FDP_ACF_EXT.3 supports the objective by ensuring that the TSF does not permit write and execute permissions on stored data to be granted simultaneously. | ||
| FDP_DAR_EXT.1 | FDP_DAR_EXT.1 supports the objective by requiring the TSF to encrypt all sensitive data using data encryption keys. | ||
| FDP_DAR_EXT.2 | FDP_DAR_EXT.2 supports the objective by requiring the TSF to provide a mechanism to mark data as sensitive so that it can be subject to encryption. | ||
| FIA_UAU_EXT.1 | FIA_UAU_EXT.1 supports the objective by requiring the presentation of a valid authorization factor in order to decrypt sensitive data at rest. | ||
| FPT_JTA_EXT.1 | FPT_JTA_EXT.1 supports the objective by requiring the TSF to enforce access controls against JTAG so that this interface cannot be used to disclose data at rest. | ||
| FPT_KST_EXT.1 | FPT_KST_EXT.1 supports the objective by requiring the TSF to prevent the storage of plaintext key data in readable non-volatile memory. | ||
| FPT_KST_EXT.2 | FPT_KST_EXT.2 supports the objective by requiring the TSF to prevent any transmission of plaintext key material outside of the TOE boundary. | ||
| FPT_KST_EXT.3 | FPT_KST_EXT.3 supports the objective by requiring the TSF to prevent export of any stored plaintext keys. |
The Security Objectives
for the TOEin Section
5 RequirementsObjectives were constructed to address threats identified in
Section 3 1 Threats.The Security Functional Requirements (SFRs) in
Section 5.1 Security Functional Requirementsare a formal instantiation of the Security Objectives. The PP identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing.
| Assurance Class | Assurance Components |
| Security Target (ASE) | Conformance Claims (ASE_CCL.1) |
| Extended Components Definition (ASE_ECD.1) | |
| ST Introduction (ASE_INT.1) | |
| Security Objectives for the Operational Environment (ASE_OBJ.1) | |
| Stated Security Requirements (ASE_REQ.1) | |
| Security Problem Definition (ASE_SPD.1) | |
| TOE Summary Specification (ASE_TSS.1) | |
| Development (ADV) | Basic Functional Specification (ADV_FSP.1) |
| Guidance Documents (AGD) | Operational User Guidance (AGD_OPE.1) |
| Preparative Procedures (AGD_PRE.1) | |
| Life Cycle Support (ALC) | Labeling of the TOE (ALC_CMC.1) |
| TOE CM Coverage (ALC_CMS.1) | |
| Timely Security Updates (ALC_TSU_EXT) | |
| Tests (ATE) | Independent Testing – Sample (ATE_IND.1) |
| Vulnerability Assessment (AVA) | Vulnerability Survey (AVA_VAN.1) |
If the application is relying on random bit generation from the host platform, the evaluator shall verify the TSS includes the name/manufacturer of the external RBG and describes the function call and parameters used when calling the external DRBG function. If different external RBGs are used for different platforms, the evaluator shall verify the TSS identifies each RBG for each platform. Also, the evaluator shall verify the TSS includes a short description of the vendor's assumption for the amount of entropy seeding the external DRBG. The evaluator uses the description of the RBG functionality in FCS_RBG_EXT or documentation available for the operational environment to determine that the key size being requested is identical to the key size and mode to be used for the encryption/decryption of the user data.
This PP does not define any Implementation-Based requirements.
As indicated in the introduction to this PP, the baseline requirements (those that must be performed by the TOE or its underlying platform) are contained in the body of this PP. There are additional requirements based on selections in the body of the PP: if certain selections are made, then additional requirements below must be included.
If the TOE acts as a receiver in the RSA key establishment scheme, the TOE does not need to implement RSA key generation.
If the application "invokes platform-provided functionality for asymmetric key generation," then the evaluator shall examine the TSS to verify that it describes how the key generation functionality is invoked.
Evaluation Activity Note: The following tests may require the developer to provide access to a developer environment that provides the evaluator with tools that are typically available to end-users of the application.
Key Generation for FIPS PUB 186-4 RSA Schemes
The evaluator shall verify the implementation of RSA Key Generation by the TOE using the Key Generation test. This test verifies the ability of the TSF to correctly produce values for the key components including the public verification exponent e, the private prime factors p and q, the public modulus n and the calculation of the private signature exponent d. Key Pair generation specifies 5 ways (or methods) to generate the primes p and q. These include:
If possible, the Random Probable primes method should also be verified against a known good implementation as described above. Otherwise, the evaluator shall have the TSF generate 10 keys pairs for each supported key length nlen and verify:
FIPS 186-4 ECC Key Generation Test For each supported NIST curve, i.e., P-256, P-384 and P-521, the evaluator shall require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated using an approved random bit generator (RBG). To determine correctness, the evaluator shall submit the generated key pairs to the public key verification (PKV) function of a known good implementation.
FIPS 186-4 Public Key Verification (PKV) Test For each supported NIST curve, i.e., P-256, P-384 and P-521, the evaluator shall generate 10 private/public key pairs using the key generation function of a known good implementation and modify five of the public key values so that they are incorrect, leaving five values unchanged (i.e., correct). The evaluator shall obtain in response a set of 10 PASS/FAIL values.
Key Generation for Finite-Field Cryptography (FFC)
The evaluator shall verify the implementation of the Parameters Generation and the Key Generation for FFC by the TOE using the Parameter Generation and Key Generation test. This test verifies the ability of the TSF to correctly produce values for the field prime p, the cryptographic prime q (dividing p-1), the cryptographic group generator g, and the calculation of the private key x and public key y. The Parameter generation specifies 2 ways (or methods) to generate the cryptographic prime q and the field prime p:
Cryptographic and Field Primes:
Cryptographic Group Generator:
Private Key:
Diffie-Hellman Group 14 and FFC Schemes using “safe-prime” groups
Testing for FFC Schemes using Diffie-Hellman group 14 and/or safe-prime groups is done as part of testing in CKM.2.1.
Conditioning can be performed using one of the identified hash functions or the process described in NIST SP 800-132; the method used is selected by the ST Author. SP 800-132 requires the use of a pseudo-random function (PRF) consisting of HMAC with an approved hash function. The ST author selects the hash function used, also includes the appropriate requirements for HMAC and the hash function.
Appendix A of SP 800-132 recommends setting the iteration count in order to increase the computation needed to derive a key from a password and, therefore, increase the workload of performing a password recovery attack. A significantly higher value is recommended to ensure optimal security. This value is expected to increase to a minimum of 10,000 in a future iteration based on SP800-63.
[selection:
The RSA-based key establishment schemes are described in Section 9 of NIST SP 800-56B; however, Section 9 relies on implementation of other sections in SP 800-56B. If the TOE acts as a receiver in the RSA key establishment scheme, the TOE does not need to implement RSA key generation.
The elliptic curves used for the key establishment scheme shall correlate with the curves specified in FCS_CKM.1.1/AK.
The domain parameters used for the finite field-based key establishment scheme are specified by the key generation according to FCS_CKM.1.1/AK.
Key Establishment Schemes
The evaluator shall verify the implementation of the key establishment schemes supported by the TOE using the applicable tests below.
SP800-56A Key Establishment Schemes
The evaluator shall verify a TOE's implementation of SP800-56A key agreement schemes using the following Function and Validity tests. These validation tests for each key agreement scheme verify that a TOE has implemented the components of the key agreement scheme according to the specifications in the Recommendation. These components include the calculation of the DLC primitives (the shared secret value Z) and the calculation of the derived keying material (DKM) via the Key Derivation Function (KDF). If key confirmation is supported, the evaluator shall also verify that the components of key confirmation have been implemented correctly, using the test procedures described below. This includes the parsing of the DKM, the generation of MACdata and the calculation of MACtag.
Function Test
The Function test verifies the ability of the TOE to implement the key agreement schemes correctly. To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each supported key agreement scheme-key agreement role combination, KDF type, and, if supported, key confirmation role- key confirmation type combination, the tester shall generate 10 sets of test vectors. The data set consists of one set of domain parameter values (FFC) or the NIST approved curve (ECC) per 10 sets of public keys. These keys are static, ephemeral or both depending on the scheme being tested.
The evaluator shall obtain the DKM, the corresponding TOE’s public keys (static and/or ephemeral), the MAC tag(s), and any inputs used in the KDF, such as the Other Information (OtherInfo) and TOE id fields.
If the TOE does not use a KDF defined in SP 800-56A, the evaluator shall obtain only the public keys and the hashed value of the shared secret.
The evaluator shall verify the correctness of the TSF’s implementation of a given scheme by using a known good implementation to calculate the shared secret value, derive the keying material DKM, and compare hashes or MAC tags generated from these values.
If key confirmation is supported, the TSF shall perform the above for each implemented approved MAC algorithm.
Validity Test
The Validity test verifies the ability of the TOE to recognize another party’s valid and invalid key agreement results with or without key confirmation. To conduct this test, the evaluator shall obtain a list of the supporting cryptographic functions included in the SP800-56A key agreement implementation to determine which errors the TOE should be able to recognize. The evaluator generates a set of 24 (FFC) or 30 (ECC) test vectors consisting of data sets including domain parameter values or NIST approved curves, the evaluator’s public keys, the TOE’s public/private key pairs, MACTag, and any inputs used in the KDF, such as the OtherInfo and TOE id fields.
The evaluator shall inject an error in some of the test vectors to test that the TOE recognizes invalid key agreement results caused by the following fields being incorrect: the shared secret value Z, the DKM, the OtherInfo field, the data to be MACed, or the generated MACTag. If the TOE contains the full or partial (only ECC) public key validation, the evaluator will also individually inject errors in both parties’ static public keys, both parties’ ephemeral public keys and the TOE’s static private key to assure the TOE detects errors in the public key validation function and/or the partial key validation function (in ECC only). At least two of the test vectors shall remain unmodified and therefore should result in valid key agreement results (they should pass).
The TOE shall use these modified test vectors to emulate the key agreement scheme using the corresponding parameters. The evaluator shall compare the TOE’s results with the results using a known good implementation verifying that the TOE detects these errors.
SP800-56B Key Establishment Schemes
The evaluator shall verify that the TSS describes whether the TOE acts as a sender, a recipient, or both for RSA-based key establishment schemes.
If the TOE acts as a sender, the following evaluation activity shall be performed to ensure the proper operation of every TOE supported combination of RSA-based key establishment scheme:
RSA-based key establishment
The evaluator shall verify the correctness of the TSF’s implementation of RSAES-PKCS1-v1_5 by using a known good implementation for each protocol selected in FTP_DIT_EXT.1 that uses RSAES-PKCS1-v1_5.
Diffie-Hellman Group 14
The evaluator shall verify the correctness of the TSF’s implementation of Diffie-Hellman group 14 by using a known good implementation for each protocol selected in FTP_DIT_EXT.1 that uses Diffie-Hellman group 14.
FFC Schemes using “safe-prime” groups
The evaluator shall verify the correctness of the TSF’s implementation of safe-prime groups by using a known good implementation for each protocol selected in FTP_DIT_EXT.1 that uses safe-prime groups. This test must be performed for each safe-prime group that each protocol uses.
AES-CBC Known Answer Tests
There are four Known Answer Tests (KATs), described below. In all KATs, the plaintext, ciphertext, and IV values shall be 128-bit blocks. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.
AES-CBC Multi-Block Message Test
The evaluator shall test the encrypt functionality by encrypting an i-block message where 1 < i <= 10. The evaluator shall choose a key, an IV and plaintext message of length i blocks and encrypt the message, using the mode to be tested, with the chosen key and IV. The ciphertext shall be compared to the result of encrypting the same plaintext message with the same key and IV using a known good implementation. The evaluator shall also test the decrypt functionality for each mode by decrypting an i-block message where 1 < i <=10. The evaluator shall choose a key, an IV and a ciphertext message of length i blocks and decrypt the message, using the mode to be tested, with the chosen key and IV. The plaintext shall be compared to the result of decrypting the same ciphertext message with the same key and IV using a known good implementation. AES-CBC Monte Carlo Tests The evaluator shall test the encrypt functionality using a set of 200 plaintext, IV, and key 3- tuples. 100 of these shall use 128 bit keys, and 100 shall use 256 bit keys. The plaintext and IV values shall be 128-bit blocks. For each 3-tuple, 1000 iterations shall be run as follows:
# Input: PT, IV, Key
for i = 1 to 1000:
if i == 1:
CT[1] = AES-CBC-Encrypt(Key, IV, PT)
PT = IV
else:
CT[i] = AES-CBC-Encrypt(Key, PT)
PT = CT[i-1]
The ciphertext computed in the 1000th iteration (i.e., CT[1000]) is the result for that trial. This result shall be compared to the result of running 1000 iterations with the same values using a known good implementation.
The evaluator shall test the decrypt functionality using the same test as for encrypt, exchanging CT and PT and replacing AES-CBC-Encrypt with AES-CBC-Decrypt.
AES-GCM Monte Carlo Tests
The evaluator shall test the authenticated encrypt functionality of AES-GCM for each combination of the following input parameter lengths:
The evaluator shall test the decrypt functionality using a set of 10 key, ciphertext, tag, AAD, and IV 5-tuples for each combination of parameter lengths above and obtain a Pass/Fail result on authentication and the decrypted plaintext if Pass. The set shall include five tuples that Pass and five that Fail.
The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.
AES-XTS Tests
The evaluator shall test the encrypt functionality of XTS-AES for each combination of the following input parameter lengths:
256 bit (for AES-128) and 512 bit (for AES-256) keys
Three data unit (i.e., plaintext) lengths. One of the data unit lengths shall be a non-zero integer multiple of 128 bits, if supported. One of the data unit lengths shall be an integer multiple of 128 bits, if supported. The third data unit length shall be either the longest supported data unit length or 216 bits, whichever is smaller.
Using a set of 100 (key, plaintext and 128-bit random tweak value) 3-tuples and obtain the ciphertext that results from XTS-AES encrypt.
The evaluator may supply a data unit sequence number instead of the tweak value if the implementation supports it. The data unit sequence number is a base-10 number ranging between 0 and 255 that implementations convert to a tweak value internally.
The evaluator shall test the decrypt functionality of XTS-AES using the same test as for encrypt, replacing plaintext values with ciphertext values and XTS-AES encrypt with XTS-AES decrypt.
AES-CCM Tests It is not recommended that evaluators use values obtained from static sources such as http://csrc.nist.gov/groups/STM/cavp/documents/mac/ccmtestvectors.zip or use values not generated expressly to exercise the AES-CCM implementation.
The evaluator shall test the generation-encryption and decryption-verification functionality of AES-CCM for the following input parameter and tag lengths:
Variable Associated Data Test
For each supported key size and associated data length, and any supported payload length, nonce length, and tag length, the evaluator shall supply one key value, one nonce value, and 10 pairs of associated data and payload values, and obtain the resulting ciphertext.
Variable Payload Test
For each supported key size and payload length, and any supported associated data length, nonce length, and tag length, the evaluator shall supply one key value, one nonce value, and 10 pairs of associated data and payload values, and obtain the resulting ciphertext.
Variable Nonce Test
For each supported key size and nonce length, and any supported associated data length, payload length, and tag length, the evaluator shall supply one key value, one nonce value, and 10 pairs of associated data and payload values, and obtain the resulting ciphertext.
Variable Tag Test
For each supported key size and tag length, and any supported associated data length, payload length, and nonce length, the evaluator shall supply one key value, one nonce value, and 10 pairs of associated data and payload values, and obtain the resulting ciphertext.
Decryption-Verification Process Test
To test the decryption-verification functionality of AES-CCM, for each combination of supported associated data length, payload length, nonce length, and tag length, the evaluator shall supply a key value and 15 sets of input plus ciphertext, and obtain the decrypted payload. Ten of the 15 input sets supplied should fail verification and five should pass.
AES-CTR Tests
Test 1: Known Answer Tests (KATs)
There are four Known Answer Tests (KATs) described below. For all KATs, the plaintext, IV, and ciphertext values shall be 128-bit blocks. The results from each test may either be obtained by the validator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.
To test the encrypt functionality, the evaluator shall supply a set of 10 plaintext values and obtain the ciphertext value that results from encryption of the given plaintext using a key value of all zeros and an IV of all zeros. Five plaintext values shall be encrypted with a 128-bit all zeros key, and the other five shall be encrypted with a 256-bit all zeros key. To test the decrypt functionality, the evaluator shall perform the same test as for encrypt, using 10 ciphertext values as input.
To test the encrypt functionality, the evaluator shall supply a set of 10 key values and obtain the ciphertext value that results from encryption of an all zeros plaintext using the given key value and an IV of all zeros. Five of the key values shall be 128-bit keys, and the other five shall be 256-bit keys. To test the decrypt functionality, the evaluator shall perform the same test as for encrypt, using an all zero ciphertext value as input.
To test the encrypt functionality, the evaluator shall supply the two sets of key values described below and obtain the ciphertext values that result from AES encryption of an all zeros plaintext using the given key values an an IV of all zeros. The first set of keys shall have 128 128-bit keys, and the second shall have 256 256-bit keys. Key_i in each set shall have the leftmost i bits be ones and the rightmost N-i bits be zeros, for i in [1, N]. To test the decrypt functionality, the evaluator shall supply the two sets of key and ciphertext value pairs described below and obtain the plaintext value that results from decryption of the given ciphertext using the given key values and an IV of all zeros. The first set of key/ciphertext pairs shall have 128 128-bit key/ciphertext pairs, and the second set of key/ciphertext pairs shall have 256 256-bit pairs. Key_i in each set shall have the leftmost i bits be ones and the rightmost N-i bits be zeros for i in [1, N]. The ciphertext value in each pair shall be the value that results in an all zeros plaintext when decrypted with its corresponding key.
To test the encrypt functionality, the evaluator shall supply the set of 128 plaintext values described below and obtain the two ciphertext values that result from encryption of the given plaintext using a 128-bit key value of all zeros and using a 256 bit key value of all zeros, respectively, and an IV of all zeros. Plaintext value i in each set shall have the leftmost bits be ones and the rightmost 128-i bits be zeros, for i in [1, 128]. To test the decrypt functionality, the evaluator shall perform the same test as for encrypt, using ciphertext values of the same form as the plaintext in the encrypt test as input.
Test 2: Multi-Block Message Test
The evaluator shall test the encrypt functionality by encrypting an i-block message where 1 less-than i less-than-or-equal to 10. For each i the evaluator shall choose a key, IV, and plaintext message of length i blocks and encrypt the message, using the mode to be tested, with the chosen key. The ciphertext shall be compared to the result of encrypting the same plaintext message with the same key and IV using a known good implementation. The evaluator shall also test the decrypt functionality by decrypting an i-block message where 1 less-than i less-than-or-equal to 10. For each i the evaluator shall choose a key and a ciphertext message of length i blocks and decrypt the message, using the mode to be tested, with the chosen key. The plaintext shall be compared to the result of decrypting the same ciphertext message with the same key using a known good implementation.
Test 3: Monte-Carlo Test
For AES-CTR mode perform the Monte Carlo Test for ECB Mode on the encryption engine of the counter mode implementation. There is no need to test the decryption engine.
The evaluator shall test the encrypt functionality using 200 plaintext/key pairs. 100 of these shall use 128 bit keys, and 100 of these shall use 256 bit keys. The plaintext values shall be 128-bit blocks. For each pair, 1000 iterations shall be run as follows:
For AES-ECB mode # Input: PT, Key for i = 1 to 1000: CT[i] = AES-ECB-Encrypt(Key, PT) PT = CT[i]
The ciphertext computed in the 1000th iteration is the result for that trial. This result shall be compared to the result of running 1000 iterations with the same values using a known good implementation.
Per NIST SP 800-131A, SHA-1 for generating digital signatures is no longer allowed, and SHA-1 for verification of digital signatures is strongly discouraged as there may be risk in accepting these signatures.
SHA-1 is currently included in order to comply with the TLS. If the TLS package is included in the ST, the hashing algorithms selection for FCS_COP.1/Hash must match the hashing algorithms used in the mandatory and selected cipher suites of the TLS package. Vendors are strongly encouraged to implement updated protocols that support the SHA-2 family; until updated protocols are supported, this PP allows support for SHA-1 implementations in compliance with SP 800-131A.
The intent of this requirement is to specify the hashing function. The hash selection must support the message digest size selection. The hash selection should be consistent with the overall strength of the algorithm used (for example, SHA 256 for 128-bit keys).
The following tests require the developer to provide access to a test application that provides the evaluator with tools that are typically not found in the production application.
The intent of this requirement is to specify the keyed-hash message authentication function used for key establishment purposes for the various cryptographic protocols used by the application (e.g., trusted channel). The hash selection must support the message digest size selection. The hash selection should be consistent with the overall strength of the algorithm used for FCS_COP.1/SKC.
The ST Author should choose the algorithm implemented to perform digital signatures; if more than one algorithm is available, this requirement should be iterated to specify the functionality. For the algorithm chosen, the ST author should make the appropriate assignments/selections to specify the parameters that are implemented for that algorithm.
ECDSA Algorithm Tests
SP 800-90A contains three different methods of generating random numbers; each of these, in turn, depends on underlying cryptographic primitives (hash functions/ciphers). The ST author will select the function used (if SP 800-90A is selected), and include the specific underlying cryptographic primitives used in the requirement or in the TSS. While any of the identified hash functions (SHA-1, SHA-224, SHA-256, SHA-384, SHA-512) are allowed for Hash_DRBG or HMAC_DRBG, only AES-based implementations for CTR_DRBG are allowed.
In the second selection in this requirement, the ST author selects the appropriate number of bits of entropy that corresponds to the greatest security strength of the algorithms included in the ST. Security strength is defined in Tables 2 and 3 of NIST SP 800-57A. For example, if the implementation includes 2048-bit RSA (security strength of 112 bits) and AES 256 (security strength 256 bits), then the ST author would select 256 bits.
Implementations Conforming to FIPS 140-2 Annex C.
The reference for the tests contained in this section is The Random Number Generator Validation System (RNGVS). The evaluators shall conduct the following two tests. Note that the "expected values" are produced by a reference implementation of the algorithm that is known to be correct. Proof of correctness is left to each Scheme.
If the RNG has prediction resistance enabled, each trial consists of (1) instantiate DRBG, (2) generate the first block of random bits (3) generate a second block of random bits (4) uninstantiate. The evaluator verifies that the second block of random bits is the expected value. The evaluator shall generate eight input values for each trial. The first is a count (0 – 14). The next three are entropy input, nonce, and personalization string for the instantiate operation. The next two are additional input and entropy input for the first call to generate. The final two are additional input and entropy input for the second call to generate. These values are randomly generated. “generate one block of random bits” means to generate random bits with number of returned bits equal to the Output Block Length (as defined in NIST SP 800-90A).
If the RNG does not have prediction resistance, each trial consists of (1) instantiate DRBG, (2) generate the first block of random bits (3) reseed, (4) generate a second block of random bits (5) uninstantiate. The evaluator verifies that the second block of random bits is the expected value. The evaluator shall generate eight input values for each trial. The first is a count (0 – 14). The next three are entropy input, nonce, and personalization string for the instantiate operation. The fifth value is additional input to the first call to generate. The sixth and seventh are additional input and entropy input to the call to reseed. The final value is additional input to the second generate call.
The following paragraphs contain more information on some of the input values to be generated/selected by the evaluator.
Entropy input: the length of the entropy input value must equal the seed length.
Nonce: If a nonce is supported (CTR_DRBG with no Derivation Function does not use a nonce), the nonce bit length is one-half the seed length.
Personalization string: The length of the personalization string must be less then or equal to seed length. If the implementation only supports one personalization string length, then the same length can be used for both values. If more than one string length is support, the evaluator shall use personalization strings of two different lengths. If the implementation does not use a personalization string, no value needs to be supplied.
Additional input: the additional input bit lengths have the same defaults and restrictions as the personalization string lengths.
This requirement is included if the protocol(s) selected in FTP_DIT_EXT.1.1 require the use of certificates. If the TOE implements TLS as a HTTPS/TLS server with no mutual authentication, this requirement is not applicable.
OCSP stapling and OCSP multi-stapling only support TLS server certificate validation. If other certificate types are validated, either OCSP or CRL should be claimed.
Regardless of the selection of "implement functionality or invoke platform-provided functionality," the validation is expected to end in a trusted root CA certificate in a root store managed by the platform.
This PP does not define any Implementation-dependent requirements.
As indicated in the introduction to this PP, the baseline requirements (those that must be performed by the TOE or its underlying platform) are contained in the body of this PP. There are additional requirements based on selections in the body of the PP: if certain selections are made, then additional requirements below must be included.
The evaluator shall examine the TSS to confirm that it describes the behavior of the TOE when a connection cannot be established during the validity check of a certificate used in establishing a trusted channel. The evaluator shall verify that any distinctions between trusted channels are described. If the requirement that the administrator is able to specify the default action, then the evaluator shall ensure that the operational guidance contains instructions on how this configuration action is performed.
RPM format. Applications running on Debian and Debian derivatives shall be packaged in DEB format.
This appendix lists requirements that should be considered satisfied by products successfully evaluated against this PP. These requirements are not featured explicitly as SFRs and should not be included in the ST. They are not included as standalone SFRs because it would increase the time, cost, and complexity of evaluation. This approach is permitted by [CC] Part 1, 8.2 Dependencies between components.
This information benefits systems engineering activities which call for inclusion of particular security controls. Evaluation against the PP provides evidence that these controls are present and have been evaluated.
| Requirement | Rationale for Satisfaction |
|---|---|
| FAU_SEL.1 - Selective Audit | FAU_SEL.1 has a dependency on FMT_MTD.1 since configuration of audit data is a subset of managing TSF data. This dependency is met by FMT_SMF.1, which defines "configure the auditable items" as a management function and specifies the roles that may perform this, consistent with how FMT_MTD.1 would typically satisfy the dependency. |
| FCS_CKM.1 - Cryptographic Key Generation | FCS_CKM.1 has a dependency on FCS_CKM.4 for the subsequent destruction of any keys that the TSF generates. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose. |
| FCS_CKM.1 - Cryptographic Key Generation | FCS_CKM.1 has a dependency on FCS_CKM.4 for the subsequent destruction of any keys that the TSF generates. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose as its CC Part 2 equivalent. |
| FCS_CKM.2 - Cryptographic Key Establishment | Both iterations of FCS_CKM.2 have a dependency on FCS_CKM.4 for the subsequent destruction of any keys that the TSF establishes. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose as its CC Part 2 equivalent. |
| FCS_COP.1 - Cryptographic Operation | All iterations of FCS_COP.1 have a dependency on FCS_CKM.4 for the subsequent destruction of any residual key material the TSF creates as part of the operation. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose as its CC Part 2 equivalent. |
| FCS_STG_EXT.1 - Cryptographic Key Storage | FCS_STG_EXT.1 has a dependency on FMT_SMR.1 for the management roles that are authorized to manage the functionality defined by the requirement. This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF. |
| FDP_ACF_EXT.1 - Access Control for System Services | FDP_ACF_EXT.1 has a dependency on FMT_SMR.1 for the management roles that are authorized to manage the functionality defined by the requirement. This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF. |
| FDP_ACF_EXT.2 - Access Control for System Resources | FDP_ACF_EXT.2 has a dependency on FMT_SMR.1 for the management roles that are authorized to manage the functionality defined by the requirement. This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF. |
| FIA_AFL_EXT.1 - Authentication Failure Handling | FIA_AFL_EXT.1 has a dependency on FIA_UAU.1 since handling of authentication failures is not possible without an authentication mechanism. This dependency is met by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2 equivalent. |
| FIA_PMG_EXT.1 - Password Management | FIA_PMG_EXT.1 has a dependency on FIA_UAU.1 since composition of authentication credentials is not possible without an authentication mechanism. This dependency is met by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2 equivalent. |
| FIA_UAU.7 - Protected Authentication Feedback | FIA_UAU.7 has a dependency on FIA_UAU.1 since protected authentication feedback is not possible without an authentication mechanism. This dependency is met by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2 equivalent. |
| FMT_SMF_EXT.3 - Current Administrator | FMT_SMF_EXT.3 has a dependency on FMT_SMR.1 through its reference to management roles in the requirement text. This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF. |
| Factor | Same/Different | Guidance |
| PP-Specified Functionality | Same | If the differences between Models affect only non-PP-specified functionality, then the Models are equivalent. |
| Different | If PP-specified security functionality is affected by the differences between Models, then the Models are not equivalent and must be tested separately. It is necessary only to test the functionality affected by the software differences. If only differences are tested, then the differences must be enumerated, and for each difference the Vendor must provide an explanation of why each difference does or does not affect PP-specified functionality. If the Product Models are separately tested fully, then there is no need to document the differences. |
| Factor | Same/Different | Guidance |
| Product Models | Different | Versions of different Product Models are not equivalent unless the Models are equivalent as defined in Section 3. |
| PP-Specified Functionality | Same | If the differences affect only non-PP-specified functionality, then the Versions are equivalent. |
| Different | If PP-specified security functionality is affected by the differences, then the Versions are not considered equivalent and must be tested separately. It is necessary only to test the functionality affected by the changes. If only the differences are tested, then for each difference the Vendor must provide an explanation of why the difference does or does not affect PP-specified functionality. If the Product Versions are separately tested fully, then there is no need to document the differences. |
| Factor | Same/Different/None | Guidance |
| Platform Architectures | Different | Platforms that present different processor architectures and instruction sets to the application are not equivalent. |
| PP-Specified Functionality | Same | For platforms with the same processor architecture, the platforms are equivalent with respect to the application if execution of all PP-specified security functionality follows the same code path on both platforms. |
| Factor | Same/Different/None | Guidance |
| Platform Architectures | Different | Platforms that run on different processor architectures and instruction sets are not equivalent. |
| Platform Vendors | Different | Platforms from different vendors are not equivalent. |
| Platform Versions | Different | Platforms from the same vendor with different major version numbers are not equivalent. |
| Platform Interfaces | Different | Platforms from the same vendor and major version are not equivalent if there are differences in device interfaces and OS APIs that are relevant to the way the platform provides PP-specified security functionality to the application. |
| Platform Interfaces | Same | Platforms from the same vendor and major version are equivalent if there are no differences in device interfaces and OS APIs that are relevant to the way the platform provides PP-specified security functionality to the application, or if the Platform does not provide such functionality to the application. |
| Factor | Same/Different/None | Guidance |
| Platform Type/Vendor | Different | Software-based execution environments that are substantially different or come from different vendors are not equivalent. For example, a java virtual machine is not the same as a container. A Docker container is not the same as a CoreOS container. |
| Platform Versions | Different | Execution environments that are otherwise equivalent are not equivalent if they have different major version numbers. |
| PP-Specified Security Functionality | Same | All other things being equal, execution environments are equivalent if there is no significant difference in the interfaces through which the environments provide PP-specified security functionality to applications. |
| Acronym | Meaning |
|---|---|
| Base-PP | Base Protection Profile |
| CC | Common Criteria |
| CEM | Common Evaluation Methodology |
| CMC | Certificate Management over CMS |
| CMS | Cryptographic Message Syntax |
| CN | Common Names |
| CRL | Certificate Revocation List |
| CSA | Computer Security Act |
| DEP | Data Execution Prevention |
| DES | Data Encryption Standard |
| DHE | Diffie-Hellman Ephemeral |
| DMG | Apple Disk Image |
| DNS | Domain Name System |
| DPAPI | Data Protection Application Programming Interface |
| DRBG | Deterministic Random Bit Generator |
| DSS | Digital Signature Standard |
| DT | Date/Time Vector |
| DTLS | Datagram Transport Layer Security |
| EAP | Extensible Authentication Protocol |
| ECDHE | Elliptic Curve Diffie-Hellman Ephemeral |
| ECDSA | Elliptic Curve Digital Signature Algorithm |
| ELF | Executable and Linkable Format |
| EMET | Enhanced Mitigation Experience Toolkit |
| EST | Enrollment over Secure Transport |
| FIPS | Federal Information Processing Standards |
| GPS | Global Positioning System |
| HMAC | Hash-based Message Authentication Code |
| HTTP | Hypertext Transfer Protocol |
| HTTPS | Hypertext Transfer Protocol Secure |
| IANA | Internet Assigned Number Authority |
| IEC | International Electrotechnical Commission |
| IETF | Internet Engineering Task Force |
| IP | Internet Protocol |
| IPA | iOS Package archive |
| IR | Intermediate Integer |
| ISO | International Organization for Standardization |
| IT | Information Technology |
| ITSEF | Information Technology Security Evaluation Facility |
| JNI | Java Native Interface |
| LDAP | Lightweight Directory Access Protocol |
| MIME | Multi-purpose Internet Mail Extensions |
| MPKG | Meta Package |
| MSI | Microsoft Installer |
| NFC | Near Field Communication |
| NIAP | National Information Assurance Partnership |
| NIST | National Institute of Standards and Technology |
| OCSP | Online Certificate Status Protocol |
| OE | Operational Environment |
| OID | Object Identifier |
| OMB | Office of Management and Budget |
| OS | Operating System |
| Portable Document Format | |
| PE | Portable Executable |
| PID | Process Identifier |
| PII | Personally Identifiable Information |
| PKG | Package file |
| PKI | Public Key Infrastructure |
| cPP | Collaborative Protection Profile |
| EP | Extended Package |
| FP | Functional Package |
| OE | Operational Environment |
| PP | Protection Profile |
| PP-Configuration | Protection Profile Configuration |
| PP-Module | Protection Profile Module |
| RBG | Random Bit Generator |
| RFC | Request for Comment |
| RNG | Random Number Generator |
| RNGVS | Random Number Generator Validation System |
| S/MIME | Secure/Multi-purpose Internet Mail Extensions |
| SAN | Subject Alternative Name |
| SAR | Security Assurance Requirement |
| SE | Security Enhancements |
| SFR | Security Functional Requirement |
| SHA | Secure Hash Algorithm |
| SIP | Session Initiation Protocol |
| SP | Special Publication |
| SSH | Secure Shell |
| ST | Security Target |
| SWID | Software Identification |
| TLS | Transport Layer Security |
| TOE | Target of Evaluation |
| TSF | TOE Security Functionality |
| TSFI | TSF Interface |
| TSS | TOE Summary Specification |
| UI | User Interface |
| URI | Uniform Resource Identifier |
| URL | Uniform Resource Locator |
| USB | Universal Serial Bus |
| XCCDF | eXtensible Configuration Checklist Description Format |
| XOR | Exclusive Or |
| app | Application |
| cPP | Collaborative Protection Profile |
| Identifier | Title |
|---|---|
| [CC] | Common Criteria for Information Technology Security Evaluation -
|
| [CEM] | Common Evaluation Methodology for Information Technology Security - Evaluation Methodology, CCMB-20172012-0409-004, Version 3.1, Revision 5, April 2017. |
| [OMB] | Reporting Incidents Involving Personally Identifiable Information and Incorporating the Cost for Security in Agency Information Technology Investments, OMB M-06-19, July 12, 2006. |